Enterprises need to anticipate when the processing load on their computer systems, such as a customer service system, will exceed the system capacity in order to expand the system capacity in time to avoid service outages. In some cases, delays in handling, for example, customer calls due to inadequate computer system resources can be directly linked to quantifiable losses of revenue. Expanding computer system capacity before it is required, merely to ensure that the computer system capacity is not exceeded, results in sinking enterprise capital into computing resources well before these resources are actually needed.
Enterprises may conduct load testing of their computer systems to evaluate when increasing customer service loads will exceed system capacity and to evaluate system processing barriers. For example, it may be that the computer system has adequate processing power, but that a communication bottleneck, such as between the processors and the secondary storage causes system transaction throughput to slow down.
The “busy hour” is a term of art which refers to a peak activity period for the computer system. In some circumstances, the “busy hour” may refer to a peak activity period for the computer system during a month or during a year. In some cases the annual busy hour may be the preferred test of the computer system, for example the mother's day busy hour for long distance telephone service. In other cases the monthly busy hour may be the preferred test of the computer system, for example a computer system which processes monthly reports or bills. Load testing activities may be directed to determining whether the computer system is able to process the busy hour transaction load without crashing or without exceeding response time requirements.
In the process of rolling out new or modified software or systems, it is may be preferable to test the software and systems under real-world conditions before putting them into a production environment. By creating or simulating production loads, flaws or weaknesses in the code or systems may also be uncovered and repaired or improved prior to actual implementation.